<h2>Play with this demo</h2>
<p>
In this Activity, you can : 
<ul>
  <li> start a Loader and observe Loader's progress ;
  <li> cancel a started Loader ;
  <li> start a Loader, rotate the device and observe that UI is updated as expected (no need to wait for the loader to fully completes);
  <li> after you rotated the device, the loader is still complete : starting it again will get you instantly with the 
  result (full progress) and you must cancel the loader to restart it.
  <li> rotate the device as much as you want, we implemented a workaround to the "limitation of 1 rotation bug" observed in the previous example; 
  <li> observe no more memory leak, you can start as many Loaders as you want.
</ul>
</p>

<h2>Loader with progress. </h2>

This Activity uses a simple Loader but adds support to get Loader progress. <br>

<h3>Progress and loaders </h3>
<p>
On this demo activity, you can observe the progress of the Loader's job. This hack is practical but not so clean.
It has been supplied by the community as a workaround to loader limitations on Stack OverFlow <a href="http://stackoverflow.com/q/9077212/693752">Update progressbar from AsyncTaskLoader ?</a>.
</p>

<p>
We should remember why loaders have been designed : optimizing data base access. This operation has no interest in the "progress information".
Using them for other purposes is simply using the wrong tool to achieve it. 
</p>

<iframe src="loader_common.html" width="100%" height="400" frameborder="0">
<a href="loader_common.html">Here is a discussion on loader drawbacks.</a>
</iframe>
<hr>
Next Activity provides an example of Loader usage to perform a REST request, we will demonstrate why Loaders don't fit when it comes to networking.